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[57] ABSTRACT 

A system and method for remotely accessing communica- 
tion network nodes and for monitoring each type of resource 
within such nodes in a fast, reliable and efficient manner. 
The system components are a web browser as user interface, 
a web server for generating and transmitting commands to 
the destination node using the Common Gateway Interface 
(CGI) of the web server and a dedicated multiprotocol agent 
hosted in each node communicating with the web server by 
means of an appropriate protocol. 
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REMOTE NODE MAINTENANCE AND 
MANAGEMENT METHOD AND SYSTEM IN 
COMMUNICATION NETWORKS USING 
MULTIPROTOCOL AGENTS 

BACKGROUND OF THE INVENTION 

1. Field of the Invention 

The present invention relates to remote node maintenance 
and management in communication networks and more 
particularly, to a system and method for providing access to 
communication network nodes and for monitoring each type 
of resource within the network nodes in a fast, reliable and 
efiScient manner. 

2. Description of the Related Art 

Network management is the art of managing communi- 
cation networks. Almost everybody uses a communication 
network at one time or another without always being aware 
of it. Using an automatic teller machine is an example of 
using a communication network in daily hfe. A communi- 
cation network provides means for transporting data, voice 
or video from one computer to another via a collection of 
devices, cables, circuits, etc. Linking computers through a 
network allows the sharing of computing power and infor- 
mation between users and thus increases efiBciency and 
productivity. Significant and sometimes huge amounts of 
money are invested in communication networks by organi- 
zations and companies. The maintenance of large and com- 
plex networks is a considerable task and today, even on 
medium sized networks, the maintenance is computer 
assisted so as to be more cost effective. This automated 
assistance is known as ^'network management". This process 
collects data related to the network (manually or 
automatically), processes the data, and synthesizes it in a 
human readable form to facilitate network operations. More 
sophisticated systems analyze data and suggest or even 
implement solutions. Moreover, some systems are capable 
of generating reports and statistics. 

Network management such as defined by the International 
Standards Organization (ISO) is divided into five functional 
areas: 

1. fault management, 

2. configuration management, 

3. security management, 

4. performance management, 

5. accounting management. 

Network management is in no way a monolithic process. 
It is a set of processes cooperating together. 

A communication network is made of many pieces of 
hardware equipment and software programs. For any reason, 
some may be working wrong or not working at all. The fault 
management function deals with these failures. It consists in 

1. discovering the problem, 

2. isolating the problem, and 

3. fixing the problem. 

Discovering the problem can be by means of a telephone 
call from a user or by means of the faulty device itself 
reporting the failure if it is able to do it. When the faulty 
device is down, the neighbors within the network may report 
a loss of contact or something similar. 

Isolating the problem consists in pinpointing the failing 
component (which may not be the component signalling the 
error). It is crucial to conduct investigations remotely (i.e. 
without resorting to travel). 

Fixing the problem consists in executing the proper repair 
action. In present systems, a failing device is generally able 
to indicate the appropriate corrective action. The capability 
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to download code remotely and to fix software problems 
constitutes a determinative advantage. 

In networks, some devices have a critical function, nodes 
for instance. For upgrading the hardware and software of 

5 these devices, configuration information such as serial 
numbers, engineering change numbers, supported protocols, 
etc., must be available to the network engineer. This con- 
figuration management information should also be updated 
"on the fly". Managing access rights and committed quality 

10 of service are also part of configuration management. 

Security management deals with detection of unautho- 
rized attempts to access restricted parts of the network or 
protected computers. It also involves managing firewalls, 
enforcing security on dialup lines, etc. 

15 Performance management involves congestion 
avoidance, capacity planning, and bandwidth statistics. 
More particularly, its role is to make sure that the network 
capacity is adequate with regard to the needs. 

Accounting management consists in tracking the use of 

20 the network resources by the different users or groups of 
users. The purpose may be to bill each one according to his 
resource utilization, making sure that no one exceeds the 
resources he has reserved or paid for, or to simply ensure 
fairness of usage. The accounting management function 

25 provides the financial data for capacity planning. 

Acquisition of information is essential for an efficient 
network management system. However, networks are gen- 
erally made up of disparate devices and the information 
which can be obtained is more often heterogeneous. The 

30 purpose of network management protocols such as CMIP 
(Common Management Information Protocol) or SNMP 
(Simple Network Management Protocol) is to standardize 
sets of queries. For each query of the network manager a 
particular response is specified. If every node in the network 

35 implements the same protocol, then network management 
becomes hardware independent. This is not always realistic: 
in practice when faults have to be isolated and fixed, these 
general purpose protocols are often not sufficient or 
adequate. For instance both a plane and a car may have a flat 

40 lire, but the symptoms, consequences and repair actions are 
specific to each type of vehicle. 

Building a network management system that incorporates 
all the functions previously described implies the develop- 
ment of a set of software applications or tools and their 

45 placement according to a convenient architecture in the 
communication network. The most commonly used archi- 
tectures are the following: 

1. centralized, 

2. distributed, 
50 3. hierarchical. 

A centralized architecture implies a network manager in a 
large central system running the majority of the network 
management applications. 

A distributed architecture consists in multiple peer net- 

55 work managers operating simultaneously, each one being 
responsible for a part of the network such as a group of 
countries. A hierarchical architecture is a mix of the two 
previous: the main central system of the centralized archi- 
tecture is the root of the hierarchy, accumulating all essential 

60 information and allowing access to all parts of the network. 
Then by setting up peer systems from the distributed 
architecture, it can delegate some network management 
tasks that function as children in the hierarchy. 

Each one of these approaches involves one or several 

65 management consoles at fixed location(s). I'he recent emer- 
gence of Web-based network managers makes mobile man- 
agement consoles possible. From almost anywhere, with any 
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type of computer, even from a dumb terminal, network Both are located in a NAS (Node Administration Station) 

engineers can have access to the network, obtain the data which is a personal computer component of each node. The 

they want, and perform preventive and corrective actions. PETC Server uses the same internal protocol as the NAS to 

The World Wide Web, called WWW or more simply the communicate with the line adapters of the node. A remote 

Web, is a set of servers interconnected via a protocol named 5 pEXC Client can gain access to a local PETC Server using 

IP (Internetworking Protocol). The underlying IP network is TCP/IP protocol. 

usually called the Internet. The web protocol, technically Another way to manage a network node is to use a 

termed HTTP (Hypertext Transfer Protocol) has created a combination of- 

tetorical breaklhrough: previously good knowledge of the ^ ^ ^j^^ ^^^^^^ ^ ^^^^ PgU, (p^^j 

IP protocol suite was needed to enter the right commands to n t * _f \ • .1. to** ^^^-^rx kt r» ji_ j 

. ^. 1 , . , ^ir*u TiT^ »L 10 User Interface) m the IBM 2220 Nways Broadband 

be able to have access to a server. With HTTP, the user uses q 't h h 

a graphical interface called a web browser. By simply . i>wiicn, and , . . , 

clicking with a mouse on one or multiple selection menus ^' f '^'^"^^ ^« 

called forms, the user is able to get information from a web ^^""^^ '"^^^ network architectures, a node agent is 

server. The web browser program performs by itself all the V^^^^^ m each network node to handle the CMIP or SNMP 

necessary operations for that, i.e., connection to the web protocol for network management purposes. This agent is 

server, sending of the request, decoding of the response and ^Iso used for sending a limited set of commands to the line 

display on the graphical interface. On request, a web server adapters of the node and receiving the corresponding 

may deliver different kinds of data, for example: responses. As previously with the PETC, the destination 

1. pages of text in HTML (Hypertext Markup Language) node agent may also be controlled by a remote FEUI 
format — the web browser is able to understand the HTML 20 residing in another node using the TCP/IP protocol. 

in order to present the text in a convenient way for human In network based maintenance and troubleshooting, the 

user; communication network is managed by the network man- 

2. images or sounds in different kinds of format that the web ager from one or several consoles. Commands are sent to the 
browser is able to interpret. nodes using a standard protocol such as CMIP (Common 
The web server is also called HTTPD (HTTP Daemon— 35 Management Information Protocol) or SNMP (Simple Net- 
in the world of computmg a "Daemon" is a program which ^ofj^ Management Protocol). Special appUcation programs 
is able to perform tasks that anordmary program is not developed for each type of network node running under 
allowed to do). Alessknown HTTPD feature allows the user 3 ^ ,3^^,^ j^^^^-^^ ^^^^^^1^ ^ 

to request the execution or a program instead of the deuvery , u ■ a *• u 

r J * / u i_ »\ T ^ * _r • L ment program providmg basic functions such as the user 

or a document (a web page ). In order to perform theu- job • * r • * *i. 

properly, the programs to be executed on the server side "^'f^^^^ the mterface with the operatmg system, etc. 

have to be written according to some specifications, in recent alternative consists m providmg the end user 

particular, according to the CGI (Common Gateway with a web browser like any of those currently used on the 

Interface) specifications. The programs written in accor- P^^^^^ Internet network. Two solutions can be considered: 

dance with these specifications are called CGI programs. 1* installing a web server inside each node to perform the 

Additional information about network management can 35 specific actions requested by the web browser, 

be found in the publication entitled "Network 2. using a centralized web server to send standard SNMP or 

Management — a practical perspective" by Allan Leinwand CMIP requests to the node to examine (just as traditional 

& Karen Fang published by Addison-Wesley Publishing network management products would do). 

Company, 1993. Additional information about the Web can A first solution described in FIG. 7, uses a web server on 

be found in the IBM publication "Accessing the Internet" — 40 each network node. Due to memory and processing power 

International Technical Support Centers, August 1995, constraints inside the node, this web server cannot imple- 

SG24-2597-00. Other sources of information about the Web ment all the functions of a real Internet web server and is 

are online on Web sites. For instance the National Computer often located in a ROM. The product "WebManage" from 

Science Application Web site: "httpV/hoohoo.ncsa.uiuc.edu" Tribe Computer Works Corporation is an example of such an 

gives detailed information about HTML, HTTP and CGI. 45 implementation. FIG. 7 shows three network nodes 701, 702 

Traditionally, in communication networks, maintenance and 703 communicating together through the communica- 

and troubleshooting functions are performed by using spe- tion lines 704, 705 and 706 within the same communication 

cialized hardware and software platforms. These platforms network 716. A web server 707, 708 and 709 is located 

reside in each node of the communication network and/or in inside each node. An operator 714 using a web browser 710 

dedicated equipment (the network manager). 50 has access by means of the public Internet or an Intranet 

In node based maintenance and troubleshooting, the network 715 to any of the web servers by using an HTTP 

maintenance and troubleshooting of the communication communication 711, 712 or 713. 

network are made by operating on the faulty network node A second solution, described in FIG. 8, uses a centralized 

without having the view of the complete communication web server. Three network nodes 801, 802, and 803 com- 

network. 55 municate together through communication lines 804, 805 

An example is die PETC (Product Engineering Tool and 806 within the same communication network 812. A 

written in C language). The PETC is used inside commu- centralized web server 807 generates SNMP messages 

nication nodes such as the IBM 2220 Nways Broadband towards the network nodes as a classical network manager 

Switch from International Businc^ Machines Corporation docs. An operator 813 using a web browser 811 can have 

(IBM Corp.). The PETC works according to the client/server 60 access to the web server 807. The web browser 811 sends 

paradigm: HTTP messages 815 to the web server. These messages are 

1. the client part (PETC Client) provides the user interface converted to SNMP requests by the web server and for- 
with a command line accessible through the keyboard of warded 808, 809 or 810 to the destination node. Messages 
the console; are then processed by the SNMP agent 816, 817 or 818 of 

2. the server part (PETC Server) receives the command from 65 the node. 

the client and forwards it to the destination resource in the Network management protocols like SNMP are sufficient 

node such as line adapter, switch, etc. to isolate a faulty component such as a hardware card or a 
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piece of software. However, to understand the reason for the 
failure or to perform repair actions, general purpose proto- 
cols are not always adequate. Some communication net- 
works may have special requirements which are not easy to 
implement in a general purpose product. For instance, in 5 
large networks, the network manager is scattered across 
several computers, each computer managing a sub-network. 
There is no way to have access to a node from a unique 
console. For troubleshooting, the network management 
should be done from any console connected to the network, 
regardless of its hardware and operating system. Even a 
dumb terminal should be qualified. 

Network equipment manufacturers resort to solutions 
more or less similar to PETC or FEUI. A specialized solution 
like the PETC is not user friendly since the user interface is 
in line mode. This implies that the user has to remember all 
the available commands with their associated parameters 
and to enter them via the keyboard. Moreover, the naviga- 
tion from a network node to another is cumbersome, llie 
navigation is platform dependent and requires proprietary 
software on the client side to be connected to the server. The 20 
server uses the same path as the node agent to communicate 
with the line adapters and the response time may be long in 
case of heavy tralEc. Furthermore the communication with 
the adapters is lost in case of a severe problem, at a time 
when the tool is most needed. 25 

A solution like the FEUI offers only a limited set of 
functions — the ones provided by the node agent — and the 
response time may be long when the node agent is heavily 
loaded, which often occurs in case of node failure. A 
proprietary software program must be installed on the end 
user side to remotely operate the user interface. 

One could be tempted to install a web server inside each 
target equipment. This means that the HTTP protocol would 
replace the specialized protocols like SNMP or CMIP. But 
HTTP is a protocol built to deliver documents (i.e. text files 
or images) with a nice and user friendly presentation. ■^^ 
Having a program running inside a line adapter of a network 
node dealing with presentation and languages implies dif- 
ferent versions of line adapters according to the supported 
languages. It also means upgrade of all the network node's 
hardware if something is changed in the presentation of the 
results. Delivering a large amount of data such as an image 
could also seriously impair the overall performance of a line 
adapter. Moreover, communication network nodes operate 
in real time and are embedded systems: they have only 
minimal hardware resources available in terms of memory 
and computing power. A complete web server requires a 
large amount of those resources, a "light server" would be 
useful but since it would not implement the complete 
protocol, it would not be possible to connect to this "light 
server" with a standard "off the shelf' web browser. It is ^0 
probably not reasonable to use the HTTP protocol to per- 
form every network management function for the following 
reasons: 

1. The HTTP protocol is stateless: there is no notion of 
session, no persistence of objects. From one transaction to ^5 
the next the web server forgets everything. 

2. As the HTTP protocol works in a request/response 
manner, there is no way to receive unsolicited messages 
from the network. SNMP traps and CMIP alanns which 
are essential to fault management rely on unsohcited ^0 
messages. Continuous polling of the network to track the 
network node's state changes is ruled out as a solution 
because it is a waste of bandwidth. 

SUMMARY OF THE INVENTION ^5 

The system described in this invention called "Network 
Web Agent" or NWA comprises: 
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1. A specialized web server using the Common Gateway 
Interface (CGI) to execute applications. These applica- 
tions build and send commands to the network nodes, 
analyze the responses and format them according to the 
HT^4L protocol. Applications are triggered in response to 
a request from a web browser. The response in HTML 
form is sent back to the web browser. The web server will 
be referred to below as "Network Web Agent Proxy" or 
NWAP. 

2. Multiprotocol agents which are applications running 
inside each network node. The multiprotocol agent, 
referred to below as "Network Web Agent Daemon" or 
NWAD, receives commands from an NWAP web server 
and routes them to the appropriate resource inside the 
node. It then retrieves the response from the node resource 
and forwards it to NWAP. The NWAD is also able to 
forward a command to another network node if the node 
on which it is running is not the final destination node of 
the command. The NWAD can also execute by itself some 
commands like a file transfer using a FTP (File Transfer 
Protocol). 

3. Messages exchanged between the web server NWAP and 
the multiprotocol agent's NWADs. These messages are 
exchanged using a TCP/IP connection. Each message 
contains a header to be routed by the NWADs towards the 
right resource inside the communication network. 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 shows a general view of the network management 
system according to the present invention. 

FIG. 2 shows the communication between the various 
elements of the network management system according to 
the present invention and the network nodes. 

FIG. 3 shows a flow chart describing a network node 
according to the present invention. 

FIG. 4A shows the format of a command from the web 
server NWAP to a multiprotocol agent NWAD within a 
network node. 

FIG. 4B shows the format of a response from the multi- 
protocol agent NWAD to the web server NWAP. 

FIG. 5 A shows the sequence of operations performed 
inside a multiprotocol agent NWAD when it goes through its 
initialization phase. 

FIG. 5B shows the sequence of operations performed 
inside a multiprotocol agent NWAD when it has entered its 
operational phase. 

FIG. 6 shows the layer structure of Network Web Agent 
Proxy NWAP. 

FIG. 7 shows a first example of an existing Web-based 
network management solution. 

FIG. 8 shows a second example of an existing Web-based 
network management solution. 

DESCRIPTION OF THE PREFERRED 
EMBODIMENT 

The following description and the associated figures detail 
only one example of the environment in which the invention 
can be used. In particular, the normalized protocols such as 
SNMP, CMIP, TCP/IP, the nature of the network nodes and 
the different types of resources inside, which will be men- 
tioned later on, are by no means restrictive of the scope of 
the architecture and mechanisms, or objects of this inven- 
tion. From the teaching of the present description, the person 
skilled in the art will be able to implement the invention in 
different environments. 
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General Structure 

As described in FIG. 1, the maintenance and management 
system according to the present invention comprises: 

1. a set of procedures 105 inside a web server 103. The web 
server also comprises an HTTP Daemon 104 responsible 
for handling the HTTP communications between the web 
browser 101 and the web server 103. 

2. a multiprotocol agent 106, 108, 110 running inside each 
node 107, 111, 113. 

3. a communication protocol between the web server 103 
and the multiprotocol agent 106, 108, 110 within each 
node 107, 111, 113. 

Network Web Agent Proxy 

A set of procedures 105, named NWAP (Network Web 
Agent Proxy) operates inside a web server 103. The NWAP 

105 is activated from a web browser 101. This web browser 
is able to communicate with the web server through the 
Internet or an Intranet communication network 102. The 
web browser 101 is connected to the NWAP 105 using the 
standard Common Gateway Interface (CGI) of the web 
server 103. The NWAP 105 is able to: 

1. send commands to a remote multiprotocol agent NWAD 
106 (Network Web Agent Daemon), 

2. decode the responses, and 

3. build HTML pages to display on the web browser. 
Locating the web server outside network nodes avoids the 

drawbacks described earlier, i.e., lack of resources, platform 
dependence, and data presentation merged with operational 
functions. 

Network Web Agent Daemon 

A multiprotocol agent NWAD 106, 108, 110 operates 
inside each node 107, 113, 111 of the communication 
network 112 to manage. Such multiprotocol agent NWAD is 
able to: 

L receive commands from the Web Server NWAP 105, 
2. translate them into the right protocol in order that they 
may be understood by the target resource inside the 
node — the target resource may be a network management 
(SNMP or CM IP) node agent, a node configuration 
manager, a node error log, a line adapter, etc. 
The multiprotocol agent NWAD has also the capability to 
execute general purpose commands by itself like a file 
transfer or to run successive commands under the control of 
the web server. It also has knowledge of the location of the 
network nodes (for instance, it has the capability to query the 
general directory of the network). Thus, an NWAD such as 

106 can forward commands to the appropriate node 111 or 
113 through the communication network 112 if the node 107 
where it resides is not the final destination node 111, but only 
an intermediate node. The NWAD introduces flexibility in 
the sense that the same action can be performed in different 
ways. For instance, a line adapter may be activated via a 
single command from the NWAD to the CM IP node agent, 
or by means of a succession of commands directed from the 
NWAD to the line adapter. These alternate paths are very 
useful for performing troubleshooting. Moreover a very 
large set of commands is available, extending the standard 
CMIP and SNMP commands. The use of proprietary com- 
mands speeds up the response time since the complete CMIP 
or SNMP protocol is bypassed. 

Network Web Agent Communication Protocol 

The Network Web Agent Proxy NWAP and the multipro- 
tocol agent NWAD communicate by means of a simple and 
reliable communication protocol. As illustrated in FIG. 2, 
requests from the web browser 201 to the HTIT Daemon 
203 of a web server 215 and the corresponding responses are 
transmitted using the standard HTTP protocol 202 through 
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an Interact or Intranet communication. The NWAP proce- 
dures 205 are activated from the web server 203 by means 
of the Common Gateway Interface (CGI) 204. The NWAP 
is then able to issue requests to the multiprotocol agent 
5 NWAD using a specific Network Web Agent Communica- 
tion Protocol 206. This protocol consists of independent 
transactions in a client -server mode, NWAP being the client 
and NWAD the server A transaction includes the following: 

1 . The NWAP 205 makes a request to the NWAD 207 of the 
30 destination node 209 to establish a TCP/IP connection. 

2. The NWAP 205 sends on the connection a command 
comprising a header part with routing information for the 
NWAD 212 and a data part for the target node resource 
217. The format of this command is shown in FIG. 4A and 

15 will be detailed later. 

3. A response is sent back from the NWAD to the NWAP 205 
on the same TCP/IP connection with a format described in 
FIG. 4B. 

4. Then, the connection is closed. This ensures that a failing 
20 transaction will not hinder further access to the node. 

An entry point 207 called "NWAD Gateway" may be 
defined in the communication network. Its function is to 
route the requests to distant nodes such as node 211 through 
the normal node resources 214 and with the normal network 

25 trafBc 210. TtiQ NWAD Gateway gets the destination net- 
work node TCP/IP address from the directory services 
component of the access node 209. The command from 
NWAP 205 may then be sent by NWAD gateway 207 to the 
destination NWAD 212 as a standard TCP/IP message. 

30 General Flow 

FIG. 3 shows the relationships between the different 
agents of the network management system and the compo- 
nents of the network node according to the present inven- 
tion. 

35 Web Browser and Web Server 

First, the web browser 300 sends an HTTP message to the 
web server 301. The message is generated by a human 
operator clicking on a hyperlink of a web browser page with 
a mouse as explained previously. The message is received by 

40 the "HTTP Daemon" 302 part of the web server which is in 
charge of the exchange of the HTTP messages between the 
web server and the web browser. This message triggers a 
NWAP software program 305 thanks to the CGI interface 
303 according to a mechanism which is well known by a 

45 person skilled in the art. This first request could be to get a 
screen menu. Such screen menu is dynamically built in the 
web server 301 by the software program responsible for that 
task 305 using HTML tags and forms. The requested screen 
menu is returned to the web browser 300 using the reverse 

50 path. A more detailed explanation of the NWAP structure 
will be given later on. By clicking on the proper field on the 
received menu, the user at the web browser 300 is able to 
send a second command to the web server 301 for perform- 
ing an action on a particular network node called "destina- 

55 tion node". Such an action could be for instance: 

1. activating or deactivating a line adapter, 

2. retrieving the node error log, 

3. reconfiguring a line adapter, 

4. retrieving traflSc statistics on a line, 

60 5. performing an extended test of the node. 

At the reception of this second command, the HTTP 
Daemon 302 activates a second procedure 306 for building 
a command 322 intended for the multiprotocol agent NWAD 
308 running in the network administrative station (NAS) 

65 307 of the target node. This command may be sent using a 
TCP/IP connection. 
Web Server and NWAD 
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The fact that the NWAD 308 is running on the NAS 307 
is not essential for the present invention and must be 
considered as a preferred embodiment. Another environment 
can be imagined where the NWAD is running on a special- 
ized line adapter The NAS (network administrative station) 
attached to each node is a personal computer. Its function is 
to: 

1. host the SNMP or CMIP agent of the network node, 

2. store a node configuration data base and an error log, 

3. have access to the different resources within the node, and 

4. provide a human user interface. 

The NAS is able to communicate with the line adapters 
inside the network node (for instance using TCP/IP connec- 
tions over an Ethernet Local Area Network (Ethernet LAN). 
The format of the commands 322 transmitted from the web 
server 301 to the multiprotocol agent NWAD 308 located in 
the node is detailed in FIG. 4A. The commands comprise a 
header 401 and a data field 406: 

The "header" 401 contains information used by the mul- 
tiprotocol agent NWAD 308 to route the command to the 
destination node and to select the right resource inside. 

The "destination node" field 402 contains the name of the 
node on which the specific action has to be performed. 

The "protocol" field 403 indicates the type of protocol the 
multiprotocol agent NWAD 308 must use to dialog with the 
resource within the node. This field will be described below. 

The "destination resource location" field 404 indicates 
which resource is designated. For instance it may be a 
component of the network administrative station (NAS) or a 
line adapter. The "destination resource port" field 405 indi- 
cates on which TCP/IP port a connection from the NWAD to 
the destination resource must be established. 

The "data" field 406 contains the command itself in the 
format the resource is accustomed to receive commands 
from other components within the node. 

The format of the response forwarded by the NWAD 308 
to the web server 301 as shown in FIG. 4B is very simple 
because it comprises only a data field 407. This data field is 
the response of the node resource. In fact, since the response 
flows on the same connection as the request and since the 
NWAD handles only one command at the same time (as will 
be explained below with respect to FIG. 5B), there is no 
need for additional fields as for the command. 
NWAD and Node Resource 

Because of the information contained in the command 
header, the multiprotocol agent NWAD can, by means of a 
mechanism that will be detailed below, forward the request 
to the designated resource inside the node. 
NWAD and FEUI 

For instance a command 323 may be sent to the Front End 
User Interface (FEUI) 309. The FEUI handles the requests 
coming from the operator working on the NAS. The format 
of the command, let's say "activate adapter 3" and the way 
the FEUI receives it are exactly the same as if a human user 
had clicked on "adapter 3" on the NAS panel and had 
selected the activate action. As usual, the FEUI forwards the 
command 324 to the CMIP or SNMP node agent 311, which 
sends it to the NAS router 315 through appropriate means 
such as a queuing mechanism. The NAS router 315 then 
dispatches the command 329 to the target line adapter 319 
using for instance a TCP/IP connection on the Ethernet link 
between the NAS 307 and the line adapter 319. 

After it has been routed by a line adapter router 316, the 
command 330 will finally be received by the destination line 
adapter resource 318 inside the line adapter 319. ITie 
resource 318 processes the request as if it was originated 
from the FEUI and sends the response using the reverse 
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path. When the NWAP procedure 306 receives the response, 
it decodes it, builds an HTML page and sends this page to 
the web server. This marks the end of this transaction. 
NWAD and Node Error Log 
5 Another type of transaction is to retrieve the error log 314 
from the node. This error log 314 is stored in a data base 
inside the NAS 307. The NWAP program 306 prepares a 
command for the multiprotocol agent NWAD. The data part 
contains a command 326 for the data base manager (DBM) 

312 for extracting error records. This command 326 is sent 
to the data base manager 312 in a format such as the SQL 
format (Search and Query Language). 

NWAD and Node Configuration 

For changing the content of the configuration data base 

313 within the node, the data base manager 312 uses an 
^5 "update data base" request. 

NWAD and CMIP/SNMP Reports 

The human operator at the web browser 300 can also 
request an SNMP or CMIP report. In that case, the NWAP 
procedure 306 prepares a command for the multiprotocol 

20 agent NWAD 308 with a data part in form of an SNMP or 
CMIP request. This request is sent by the NWAD 308 to the 
CMIP or SNMP interface 310 of the node using a TCP/IP 
connection 325. 
NWAD and Line Adapters 

25 For specific purposes such as network troubleshooting, 
some additional commands which are not part of the set of 
commands the node agent 311 is able to transmit, may be 
sent to the line adapters. A direct communication from the 
NWAD 308 to the line adapter 319 is then established using 

30 TCP/IP. For this purpose, an NWAD port program 317 mns 
inside the line adapter 319 waiting for a command 327 on 
the TCP/IP port. When the command is received, it is then 
forwarded to the destination line adapter resource 318 inside 
the line adapter 319. 

35 Node Web Agent Daemon 

FIGS. 5Aand 5B are flow charts describing the operating 
mode of the mutiprotocol agent NWAD. The NWAD first 
performs an initialization sequence as shown in FIG. SAand 
then is placed in an operational mode as shown in FIG. 5B. 

40 Initial Phase 

As illustrated in FIG. 5 A, during its initial phase the 
NWAD performs the following: 

Step 502: retrieves the NAS IP address on which it is 
running by requesting said address to the NAS TCP/IP 
45 layer 

Step 503: determines the name of the node on which it is 
running by consulting the node configuration data base. 

Step 504: builds an internal routing table associating the 
names of the network nodes with their IP address. For that 
50 purpose the NWAD uses the Directory Services of the 
network (located inside each node). This routing table 
allows routing of the commands 401 according to the 
destination node field 402 after conversion to the node IP 
address. 

55 The availability of this routing table under control of the 
NWAD is not mandatory but improves performance since 
this information does not have to be requested for each new 
command. 

Step 505: waits for a connection request from the web server 
60 or from another NWAD. 
Operational Phase 

As illustrated in FIG. 5B, after the previously described 
initial phase, the NWAD is placed in an infinite loop waiting 
for a connection request from the web server. 
65 Step 506: When the NWAD receives a connection request 
from the web server or from another NWAD, it accepts 
the request, and waits for a command. 
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Steps 507/508: When the NWAD receives a complete com- 
mand (Step 507), it decodes it (Step 508) according to the 
format detailed in FIG, 4A. 

Step 509: The NWAD checks the destination by testing the 
destination node 402 field. The NWAD determines if the 5 
command is for the node where it resides or not. 

Step 510: If the command is not for the node where the 
NWAD resides, a connection is established with the 
destination node using the NWAD routing table. The 
command is sent to this destination node. lo 

Step 511: If the command is for the node where the NWAD 
resides, the protocol field 403 of the command is checked. 
If the protocol indicates that the command is for the 
NWAD, the command is executed. A command for the 
NWAD may be for instance a file transfer on the NAS is 
local disk or a standard TCP "ping" command towards a 
line adapter to see if it is alive (Note: on an Internet or 
Intranet network, "ping'* is the easiest command to test if 
it is possible to communicate with anyone else on the 
network). 20 

Step 512: If the command is local and the protocol field 403 
indicates that the command is for a line adapter, the 
destination resource location field 404 gives the position 
of this line adapter within the node. The port number 
indicated in the destination resource port field 405 allows 25 
the NWAD to start a TCP/IP communication and to send 
the command to the NWAD port component 317 of this 
line adapter. 

Step 513: If the destination is the local node and the protocol 
field 403 indicates that the command is directed to the 30 
node agent, a TCP/IP connection is established between 
the NWAD and the node agent and the command is 
forwarded to the node agent within the NAS. 

Steps 514, 515, 516: The process is the same for the local 
FEUI, the local SNMP or the local CMIP agent. 35 

Step 517: The protocol field 403 may also indicate that the 
NWAD must execute a sequence of commands called 
scenario. In that case, the data field 406 of the command 
contains this scenario which is a program prepared by the 
web server and directly executable by the multiprotocol 40 
agent NWAD. This may be used for instance to perform 
a complex set of accesses lo one of the NAS data bases. 
The advantage is that the scenario is executed locally 
instead of requiring multiple data exchanges between the 
web server and NWAD. 45 

Step 518: After transmission of the command, the NWAD 
starts a timer and waits for a response from the destination 
resource. 

Step 519: The response is sent back to the web server or to 
the NWAD which has transmitted the command using the so 
same TCP/IP connection as for the command. 
Step 520: The connection is closed and the NWAD is ready 
to accept a new connection request. 
NWAD works according to the Web concepts: to each 
new command there conesponds a new connection. This 5S 
connection is used lo send one command and get the 
corresponding response. This concept has been extended to 
the private communication between the NWAP server and 
NWAD, and between NWAD and the line adapter resources. 
This mode of operation is done for reliability purpose which 60 
is essential for an efficient remote maintenance system. If 
something goes wrong with one command, a new connec- 
tion is opened and the current one is aborted. 
Network Web Agent Proxy 

The layer structure of Network Web Agent Proxy 65 
(NWAP) is illustrated in FIG. 6 and described below. 
HTTP Daemon 
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The HTTP Daemon 601 receives the HTTP requests from 
the web browser. For instance such a request could be: 
"http://nwaserv/cgi-bin/ 

LineAdapterMenu.cmd?Nodename" 
where: 

"http" is the protocol used to communicate between the 

web browser and the web server; 
"nwaserv" is the name of the web server; 
"cgi-bin" is the directory on the web server where the 

CGI programs are located; 
"LineAdaplerMenu.cmd" is the name of the file con- 
taining the NWAP program to execute; 
"Nodename" is an input parameter for this program. 
Presentation Layer 

The presentation layer 604 of the NWAP is in charge of 
building menus. This is done using HTML tags, hyperlinks 
to other menus and forms for the user for selecting an action. 
The web request generated by the web browser after the 
selection of an action by the human user is of the type: 
"http://nwaserv/cgi-bin/ 

LineAdapterCommand.cmd?NodeName + 
AdapterNumber'*. 
Upon reception of this request, the web server starts the 
program "LineAdapterCommand" in the cgi-bin directory 
with the parameters "NodeName" and "AdapterNumber". If 
additional parameters such as the command identifier 
selected by the user in the HTML form are needed, the CGI 
interface 602 sets the environment variables of the web 
server according to their value. The program "LineAdapter- 
Command" can then retrieve them to build the data field of 
the command according to FIG, 4. 
Command Builder 

The "LineAdapterCommand.cmd" program is contained 
in the command builder component 605 of the NWAP. Said 
command builder is in charge of preparing the data field 406 
of the NWAP/NWAD command. The command builder 605 
then calls the NWAD interface component 606 of the NWAP 
to establish a TCP/IP connection with NWAD and send the 
command over it. 
NWAD Interface 

The NWAD interface 606 is responsible for physically 
sending commands. The transmission is done by means of a 
TCP/IP connection. The NWAD Interface 606: 

1. establishes the connection with NWAD, 

2. sends the data, and 

3. waits indefinitely for a response. 

When the response is received, the command builder 605 
analyzes it, prepares an HTML page with the response 
formatted in a convenient way for a human user to interpret 
it easily and forwards it to the CGI interface 602. The CGI 
interface 602 gives it lo the HTTP Daemon 601 of the web 
server which transmits it to the web browser. 

In summary, the present invention has the following 
advantages: 

1. The present network maintenance and management sys- 
tem does not depend on a specific software or hardware 
platform as traditional solutions do. Web browsers and 
web servers are commercially available for virtually any 
existing platform. 

2. The user interface (web browser) is user friendly and quite 
universal. 

3. The system is fault tolerant since it is based on indepen- 
dent transactions. 

4. The system has only a minor impact or no impact at all on 
the embedded code running inside the node resources, 
since all of the process is done inside the web server. 

5. Any command can be sent to the node resources, since 
there is no "filtering" (by a CMIP or SNMP agent, for 
instance). 
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6. The multiprotocol agent NAVAD is able to connect to a destination resource port address for establishing a 
different kinds of interfaces and thus offers a great flex- TCP/IP connection between the multiprotocol agent 
ibility to the system. and the line adapter inside the node containing the 

7. The system offers a quick response lime since it avoids destination resource. 

going through the SNMP or CMIP stack which corre- 5 5. The maintenance and management system for a remote 

spends to thousandsof lines of code. Due to the capabUity according to claim 1 wherein said multiprotocol agent 

of the NWAD to perform scenarios, it also allows the i" ^^^^ farther comprises: 

execution of a sequence of commands locaUy inside the ^ transmitter module for transmitting a response from the 

node instead of sequencing them from the web server. destination resource to the web server or to a neigh- 

8. The system uses the communication network to reach the lO , ^^"^6 ^^^^S P^^^ "^^^ ^7^^- 
nodes instead of specialized Unes. 5* mamtenance and management system for a remote 
While the invention has been particularly shown and *° ^[^''^ ^^^V^"^' 

described with reference to the particular embodiments for each command sent by the web server a new connec- 

thereof, it will be understood by those skilled in the art that ^ established; 

various changes in form and deUil may be made therein is the response associated with said command is returned to 

without departing from the spirit and scope of the invention. "^^8 connection; 

What we claim is* ^ connection is closed after the response has been 

1. A maintenance and management system for a remote , U;ansmitted to the web server. 

node in a communication network having a pluraUty of 7. The mamtenance and management system for a remote 
nodes interconnected with communication lines, each node 20 "^^^ according to claim 6 wherein said commands and 

having at least one resource, said system comprising: responses exchanged between the web server and the mul- 

. . 1 J. tiprotocol agents are transmitted over TCP/IP connections, 

a web server includmg: o tn. • * j . . r 

1 . r J- J . *>• The mamtenance and management system for a remote 

a network web agent proxy for sending a comrnand to ^^^^^ ^j^.^ g ^^^^^ commands from the web 

a destination resource in any destination node of a ^ zL e *u j *• 

, , <, j-ij- nz server and responses from the destmation resources are 

commumcation network, said command including 25 j «u u . i i- j . i j 

A . a f J J . transmitted through the network hnes and network nodes, 

an identmcation of the destmation resource and at n Tn, • « a . * c 

least one re uest' maintenance and management system tor a remote 

^ ' node according to claim 1 wherein said web server receives 

a multiprotocol agent attached to each node including: requests and sends responses, in particular HTML pages, to 

a receiver module for receivmg a command from the i^^st one web browser through an internet or intranet 

web server; network, 

a conversion module for converting the at least one ^q. The maintenance and management system for a 

request mcluded in said command in a protocol remote node according to claim 1 wherein said destination 

understandable by the destination resource within resource is a multiprotocol agent. 

the node, -j^^ maintenance and management system for a 

a transmitter module for transmitting said converted at remote node according to claim 1 wherein said destination 

least one request to the destination resource. resource is a line adapter. 

2. The maintenance and management system for a remote 12. The maintenance and management system for a 
node according to claim 1 wherein said multiprotocol agent .^raote node according to claim 1 wherein said destination 
in each node further comprises: .^^^urce is an error log. 

a receiver module for receiving the command from 13. jhe maintenance and management system for a 

another multiprotocol agent in another node wherein remote node according to claim 1 wherein said destination 

said command includes an identification of the desti- resource is a configuration data base, 

nation node; 14 j^g maintenance and management system for a 

a network web agent daemon gateway for routing the remote node according to claim 1 wherein said destination 

command to a multiprotocol agent in the destination resource is a CMIP or SNMP interface, 

node containing the destination resource or to a mul- 15. The maintenance and management system for a 

tiprotocol agent in a neigh boring node along the path remote node according to claim 1 wherein said destination 

to the destination node containing the destination resource is a front end user interface, 

resource. 16. A maintenance and management method for a remote 

3. The maintenance and management system for a remote node in communication network having a plurality of nodes 
node according to claim 2 wherein each command sent by interconnected with communication lines, each node having 
the web server to the multiprotocol agent comprises: at least one resource, said method comprising the steps of: 

a data field including at least one request; and sending a command from a web server to a destination 

a header field for routing said at least one request to the 55 resource in any destination node of a communication 

destination resource. network, said command including an identification of 

4. The maintenance and management system for a remote the destination resource and at least one request; 
node according to claim 3 wherein said header field com- receiving a command from the web server at a multipro- 
prises: tocol agent attached to each node; 

a destination node identifier for routing the command converting the at least one request included in said 

from the web server to the destination node; command in a protocol understandable by the destina- 

a protocol identifier for adapting the at least one request tion resource within the node; and 

transmitted in the data field in a protocol understand- transmitting said converted at least one request to the 

able by the destination resource; destination resource, 
a destination resource identifier for routing said at least 65 17. The maintenance and management method for a 

one request transmitted in the data field to the destina- remote node according to claim 16 further comprising the 

tion resource within the node; steps of: 
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receiving a command from another multiprotocol agent in 
another node wherein said command includes an iden- 
tification of the destination node; and 

routing the command to a multiprotocol agent in the 
destination node containing the destination resource or 
to a multiprotocol agent in a neigh boring node along 
the path to the destination node containing the desti- 
nation resource. 

18. The maintenance and management method for remote 
node according to claim 17 wherein each command sent by 
the web server to the multiprotocol agent comprises: 

a data field including at least one request; and 
a header field for routing said at least one request to the 
destination resource. 

19. The maintenance and management method for a 
remote node according to claim 18 wherein said header field 
comprises: 

a destination node identifier for routing the command 
from the web server to the destination node; 

a protocol identifier for adapting the at least one request 
transmitted in the data field in a protocol understand- 
able by the destination resource; 

a destination resource identifier for routing said at least 
one request transmitted in the data field to the destina- 
tion resource within the node; and 

a destination resource port address for establishing a 
TCP/IP connection between the multiprotocol agent 
and the line adapter inside the node containing the 
destination resource. 
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20. The maintenance and management method for a 
remote node according to claim 16 further comprising: 

transmitting a response from the destination resource to 
the web server or to a neigh boring node along the path 
to the web server. 

21. The maintenance and management method for a 
remote node according to claim 20 including the steps of: 

establishing a new connection for each command sent by 

the web server; 
transmitting a response associated with said command to 

the web server using the new connection; and 
closing said new connection after the response has been 

transmitted to the web server. 

22. The maintenance and management method for a 
remote node according to claim 21 wherein said commands 
and responses exchanged between the web server and the 
multiprotocol agents are transmitted over TCP/IP connec- 
tions. 

23. The maintenance and management method for a 
remote node according to claim 21 wherein commands from 
the web server and responses from the destination resources 
are transmitted through the network lines and network 
nodes. 

24. The maintenance and management method for a 
remote node according to claim 16 wherein said web server 
receives requests and sends responses, in particular HTML 
pages, to at least one web browser through an internet or 
intranet network. 
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